Docs: Expand QUnit.config.testFilter docs#1815
Docs: Expand QUnit.config.testFilter docs#1815gbudjeakp wants to merge 1 commit intoqunitjs:mainfrom
Conversation
|
|
gbudjeakp
force-pushed
the
feature/test-filter
branch
from
3d440fd to
a2d1e2a
Compare
|
|
||
| 1. **Test-level filters** run first: [`test.only()`](../QUnit/test.only.md), [`test.skip()`](../QUnit/test.skip.md), [`test.if()`](../QUnit/test.if.md) | ||
| 2. **Programmatic filter** runs next: `QUnit.config.testFilter` | ||
| 3. **CLI/URL filters** run last: [`--filter`](./filter.md), [`--module`](./module.md), [`--moduleId`](./moduleId.md), [`--testId`](./testId.md) |
There was a problem hiding this comment.
In terms of code and execution order it is:
- Test methods
test.onlynarrows irrevocably, removal is final. - Test methods
test.ifandtest.skipdisable irrevocably but don't remove (later layers see it). config.moduleId, narrows irrevocably.config.testId, narrows, and inclusion is immediate and final. Later layers don't even run.config.module, narrows irrevocably.config.filter, narrows irrevocably.config.testFilter, narrows further, seeing ony what hasn't been filtered out before, except for if/skip, which do get seen here. A testFilter cannot re-enable a skipped tesrt, but it can decide whether to filter. The effect is whether or not the skipped test is reported. This makes sense when distributing tests, because a skipped test should be allocated and reported on, once, just like any other test.
The order documented here is different, but maybe the order doesn't matter? Is there a specific meaning conveyed with this order? Would it mean something different to you as a user, if the order was described as 1) CLI, 2) Programmatic, 3) Test-level? This isn't a suggestion, I'm only asking as example, to help understand intent.
There was a problem hiding this comment.
I structured the docs conceptually (test-level → programmatic → CLI) thinking it would be easier to understand ( That's the way I was thinking about it at the time in my head with the scenarios I was thinking off). The order doesn't matter here but from a users perspective(especially for debugging), that might be a bit confusing. I should update the doc to match.
The correct order is:
- Test-level filters run first:
test.only(),test.skip(),test.if() - CLI/URL filters run last:
--filter,--module,--moduleId,--testId - Programmatic filter runs last:
QUnit.config.testFilter
Krinkle
left a comment
Krinkle
left a comment
There was a problem hiding this comment.
I'm landing the 2.x backport first, so the docs review is non-blocking. No rush :)
Krinkle
force-pushed
the
feature/test-filter
branch
from
b773f42 to
b795e77
Compare
|
I've landed a minimal version in 1ee3e2c for the 2.25.0, docs site, and release notes. I've then rebased this PR to iterate on the docs further. |
Krinkle
changed the title
2 participants
This PR implements
QUnit.config.testFilter, a new configuration option that allows programmatic filtering of tests at runtime through a callback function.Context:
Currently,
QUnitprovides filtering through CLI parameters (--filter, --module, etc.) and test-level methodstest.only(),test.skip(), but there's no way to implement dynamic, programmatic filtering based on runtime conditions without modifying test code.This feature enables several important use cases:
Fixes #1814.